| Document status | 35 - Reviewed |
|---|
Networking
This document describes the network architecture and configuration for EnergyConnect. The infrastructure follows a hub-and-spoke network topology with centralized connectivity services.
Overview
EnergyConnect uses a multi-subscription architecture where each environment is deployed in its own Azure subscription with a dedicated Virtual Network (VNet). All VNets are peered with a central connectivity VNet that hosts shared resources like Azure Bastion, Azure Front Door and a Container Registry.
The Bastion host allows secure SSH/RDP access to virtual machines (VMs) in each environment without exposing them to the public internet. Connecting to the Bastion host makes it possible to connect to VMs in any peered VNet / environment.
Similar does the Container Registry provide a shared location for container images used by Azure Container Apps across all environments, since various Docker Images are common across environments.
This also reduces costs by having a single Bastion host for multiple environments instead of deploying separate Bastion hosts in each environment.
Key Components
| Component | Purpose |
|---|---|
| Virtual Network (VNet) | Isolated network for each environment |
| NAT Gateway | Provides outbound internet connectivity with static public IP |
| Network Security Groups (NSGs) | Controls inbound/outbound traffic at subnet level |
| VNet Peering | Connects VNets to shared connectivity VNet |
| Azure Bastion | Secure remote access to VMs without public IPs |
| Azure Front Door | Global load balancing and WAF for web applications |
Virtual Network Configuration
Each environment has a dedicated VNet divided into three subnets, each serving a specific purpose.
Subnet Architecture
| Subnet | Purpose | Delegation | NAT Gateway | Default Outbound |
|---|---|---|---|---|
| Container Subnet | Azure Container Apps | Microsoft.App/environments | Yes | Disabled (Private) |
| Database Subnet | PostgreSQL VMs | None | Yes | Disabled (Private) |
| Agent Pool Subnet | Self-hosted DevOps agents | None | Yes | Disabled (Private) |
All subnets are private subnets with no default outbound access. Outbound connectivity is provided exclusively through the NAT Gateway to ensure a consistent, known egress IP address.
NAT Gateway
Each VNet includes a NAT Gateway to provide outbound internet connectivity for all private subnets. This ensures:
- Consistent egress IP: All outbound traffic uses the same public IP, which can be whitelisted by external services
- No public IPs on resources: VMs and Container Apps remain private
- Zone redundancy: The public IP is deployed across all availability zones (1, 2, 3)
Note: The NAT Gateway was originally required because DataHub 2.0 whitelisted our public egress IP. DataHub 2 is retired, and DataHub 3 Phase 3 does not require IP whitelisting, so this is no longer a DataHub-driven requirement.
Resource Locks
In production environments, the NAT Gateway and its public IP have CanNotDelete locks to prevent accidental deletion.
Network Security Groups (NSGs)
NSGs control traffic flow at the subnet level. Each subnet type has its own NSG with specific rules.
Container Subnet NSG
The Container NSG has no custom security rules defined - it relies on Azure Container Apps' built-in network isolation.
Database Subnet NSG
| Rule Name | Direction | Port | Source | Destination | Action |
|---|---|---|---|---|---|
| Allow-Inbound-22-from-Bastion | Inbound | 22 (SSH) | Bastion Subnet CIDR | VirtualNetwork | Allow |
This rule allows SSH access from the Azure Bastion subnet to database VMs for administrative access.
Agent Pool Subnet NSG
| Rule Name | Direction | Priority | Port | Source | Destination | Action |
|---|---|---|---|---|---|---|
| allow-https-outbound | Outbound | 100 | 443 | * | * | Allow |
| allow-http-outbound | Outbound | 101 | 80 | * | * | Allow |
| Allow-Inbound-22-from-Bastion | Inbound | 200 | 22 | Bastion Subnet CIDR | VirtualNetwork | Allow |
The agent pool requires outbound HTTP/HTTPS for communicating with Azure DevOps and pulling container images.
VNet Peering
VNets are peered with a central connectivity VNet to enable access to shared resources (Bastion, Front Door).
Peering Configuration
Two peering connections are established:
-
Local to Remote (Customer VNet → Connectivity VNet)
- Deployed in customer's networking resource group
-
Remote to Local (Connectivity VNet → Customer VNet)
- Deployed in the connectivity subscription
- Uses naming:
peer-to-{customer}-{environment}
Peering Properties
| Property | Value | Description |
|---|---|---|
| allowVirtualNetworkAccess | true | Allow VNet-to-VNet traffic |
| allowForwardedTraffic | false | Don't forward third-party traffic |
| allowGatewayTransit | false | No VPN gateway transit |
| useRemoteGateways | false | Don't use remote VPN gateway |
Azure Front Door
Azure Front Door is deployed as a global load balancer and CDN for the client web application and documentation apps.
Shared Front Door Profile
A single Front Door profile (ec-global-connectivity-afd) is shared across all customer environments, deployed in the global connectivity subscription.
Components per Environment
Each environment gets:
| Component | Naming Pattern | Description |
|---|---|---|
| Endpoint | ec-{environment}-fde | Public entry point for the environment |
| Origin Group | {customer}-{environment}-origin-group | Groups Container App backends |
| Origin | {service}-origin | Points to Container App FQDN (e.g., client-origin, docs-origin) |
| Custom Domain | customer-specific | Validated via DNS TXT/CNAME records |
| Route | Links endpoint to origin group | With custom domain association |
Traffic Flow
User → Front Door (Custom Domain) → Origin Group → Container App (private FQDN)
↓
WAF Policy (shared)
Custom Domain Configuration
Custom domains require DNS records in the domain's DNS zone:
- TXT Record: For domain validation
- CNAME Record: Points to the Front Door endpoint hostname
Container App Environment
Azure Container Apps are deployed in a managed environment with VNet integration.
Network Configuration
| Property | Value |
|---|---|
| Public Network Access | Enabled |
| Infrastructure Subnet | Container Subnet (delegated to Microsoft.App/environments) |
| Zone Redundant | false |
Ingress Configuration
| App | Ingress | External | Port |
|---|---|---|---|
| Client (Angular) | Enabled | true (via Front Door) | 80 |
| ECC API | Enabled | false (internal only) | 8080 |
| DMC API | Enabled | false (internal only) | 8080 |
| NTS API | Enabled | false (internal only) | 8080 |
| Docs | Enabled | true (via Front Door) | 80 |
Outbound Connectivity
Container Apps use the NAT Gateway for outbound traffic. The NAT Gateway's public IP may be whitelisted for:
- External storage account access
- Other third-party services
Note: DataHub 3 Phase 3 does not require IP whitelisting. The former DataHub 2.0 whitelisting requirement is retired.
Network Watcher
Azure Network Watcher is deployed in each environment's networking resource group for:
- Network diagnostics
- Connection troubleshooting
- Packet capture
- NSG flow logs (if configured)
The Network Watcher is a required component for monitoring and diagnosing network issues within the VNets.
If a Network Watcher is not already enabled in the region per subscription, Azure will automatically deploy it